home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / software-eng / part1 < prev    next >
Text File  |  1995-07-25  |  14KB  |  319 lines

  1. Subject: FAQ 1: comp.software-eng questions and answers
  2. Newsgroups: comp.software-eng,comp.answers,news.answers
  3. From: dalamb@qucis.queensu.ca (David Alex Lamb)
  4. Date: 1 Nov 1994 15:38:03 GMT
  5.  
  6. Last-Modified:  1 Nov 1994
  7. Archive-name: software-eng/part1
  8.  
  9. This message gives brief answers to questions that have occurred in
  10. comp.software-eng; in many cases they are also topics many readers would like
  11. NOT to see discussed again soon.  Questions are:
  12.     What's a CASE Tool?
  13.     What's a 'function point'?
  14.     What's the 'spiral model'?
  15.     What is a 'specmark'?
  16.     Where can I find a public-domain tool to compute metrics?
  17.     How do I write good C style?
  18.     What is 'Hungarian Notation'?
  19.     Are lines-of-code (LOC) a useful productivity measure?
  20.     Should software professionals be licenced/certified?
  21.     How do I get in touch with the SEI?
  22.     What is the SEI maturity model?
  23.     Where can I get information on API?
  24.     What's a 'bug'?
  25.     Where can I get copies of standards??
  26.  
  27.  
  28.  
  29. ------------------------------------------------------------------------
  30. Subject: What's a CASE Tool?
  31. Date: 27 Oct 1994
  32. Archive file: casemsg (thanks to Scott McGregor <mcgregor@netcom.com> for
  33. inspiring this question)
  34.  
  35. CASE stands for Computer Aided Software Engineering;  it can be used to mean
  36. any computer-based tool for software planning, development, and evolution.
  37. Various people regularly call the following 'CASE': Structured Analysis (SA),
  38. Structured Design (SD), Editors, Compilers, Debuggers, Edit-Compile-Debug
  39. environments, Code Generators, Documentation Generators, Configuration
  40. Management, Release Management, Project Management, Scheduling, Tracking,
  41. Requirements Tracing, Change Management (CM), Defect Tracking, Structured
  42. Discourse, Documentation editing, Collaboration tools, Access Control,
  43. Integrated Project Support Environments (IPSEs), Intertool message systems,
  44. Reverse Engineering, Metric Analyzers.
  45.  
  46.  
  47. ------------------------------------------------------------------------
  48. Subject: What's a 'function point'?
  49. Date: 31 Jul 1993
  50. Archive file: funcpoints
  51.  
  52. Function points and feature points are methods of estimating the "amount of
  53. functionality" required for a program, and are thus used to estimate project
  54. completion time.  The basic idea involves counting inputs, outputs, and other
  55. features of a description of functionality.  If interested, for a fee you can
  56. join:
  57.     International Function Point Users Group
  58.     5008-28 Pine Creek Drive
  59.     Blendonview Office Park
  60.     Westerville, Ohio  43081-4899
  61.  
  62.  
  63. ------------------------------------------------------------------------
  64. Subject: What's the 'spiral model'?
  65. Date: 27 Oct 1994
  66. Archive file: spiral
  67.  
  68.  (1)   Barry Boehm, "A Spiral Model of Software Development and Enhancement",
  69.        ACM SIGSOFT Software Engineering Notes, August 1986.
  70.  (2)   Barry Boehm "A Spiral Model of Software Development and Enhancement"
  71.        IEEE Computer, vol.21, #5, May 1988, pp 61-72.
  72.  
  73. Basically, the idea is incremental development, using the waterfall model for
  74. each step; it's intended to help manage risks.  Don't define in detail the
  75. entire system at first.  The developers should only define the highest
  76. priority features. Define and implement those.  With this knowledge, they
  77. should then go back to define and implement more features in smaller chunks.
  78.  
  79.  
  80. ------------------------------------------------------------------------
  81. Subject: What is a 'specmark'?
  82. Date: 27 Oct 1994
  83. Archive file: specmark
  84.  
  85. The SPECmark is the geometric mean of a series of benchmarks done by the SPEC
  86. group. There are a couple of suites, but in general SPECmark refers to the
  87. results of the first suite.  The suite includes FORTRAN and C codes, mostly
  88. well known codes but slightly hacked versions.
  89.     SPEC
  90.     c/o NCGA
  91.     2722 Merrilee Drive, Suite 200
  92.     Fairfax, VA 22031
  93.     Phone: (703) 698-9600
  94.     FAX:   (703) 560-2752
  95.  
  96.  
  97. ------------------------------------------------------------------------
  98. Subject: Where can I find a public-domain tool to compute metrics?
  99. Date: 27 Oct 1994
  100. Archive file: static.html
  101.  
  102. Volume 20 of newsgroup comp.sources.unix contained a public-domain package
  103. called "metrics", which computes McCabe and Halstead metrics.  There are many
  104. comp.sources.unix archives around the net.
  105.  
  106.  
  107. ------------------------------------------------------------------------
  108. Subject: How do I write good C style?
  109. Date: 27 Oct 1994
  110.  
  111. This is answered regularly in the comp.lang.c FAQ.  Try "Recommended C style
  112. and Coding Standards", via anonymous FTP to site archive.cis.ohio-state.edu in
  113. directory pub/style-guide
  114.  
  115.  
  116. ------------------------------------------------------------------------
  117. Subject: What is 'Hungarian Notation'?
  118. Date: 27 Oct 1994
  119. Archive file: hungarian
  120.  
  121. A naming convention for C code.  See Charles Simonyi and Martin Heller, "The
  122. Hungarian Revolution", BYTE, Aug. 1991 (vol. 16, no. 8).  There are other
  123. naming conventions;  see, e.g.  "A Guide to Natural Naming", Daniel Keller,
  124. ETH, Projekt-Zentrum IDA, CH-8092 Zurich, Switzerland. Published in SIGPLAN
  125. Notices, Vol. 25, No. 5, pages 95-102.
  126.  
  127.  
  128. ------------------------------------------------------------------------
  129. Subject: Are lines-of-code (LOC) a useful productivity measure?
  130. Date: 27 Oct 1994
  131. Archive file: static.html
  132.  
  133. Not unless you are very careful.  Capers Jones' book has a detailed and
  134. insightful discussion of Lines of Code, including anomalies, and shows how to
  135. use it sensibly (eg in a single job shop, with a single language, and a
  136. standard company coding style).  It is easy to cook up anomalies where LOC
  137. gives different numbers for code written in different styles, but pathological
  138. cases should get caught in code inspections.  References:
  139. -    T. Capers Jones, Programming Productivity, McGraw-Hill, New York, 1986
  140. -    Capers Jones, Applied Software Measurement: Assuring Productivity and
  141.      Quality, McGraw-Hill, Inc., 1991, 494 pages ISBN 0-07-032813-7
  142.  
  143. The appendices of the latter give rules for counting procedural source code,
  144. as well as rules for counting function points and feature points.  The
  145. following study, cited in Boehm's _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g _E_c_o_n_o_m_i_c_s, claims that
  146. anomalies that seriously "fool" the LOC metric show up rarely in real code.
  147. -    R. Nelson _S_o_f_t_w_a_r_e _D_a_t_e _C_o_l_l_e_c_t_i_o_n _a_n_d _A_n_a_l_y_s_i_s _a_t _R_A_D_C, Rome Air
  148.      Development Center, Rome, NY.  1978.
  149.  
  150.  
  151. ------------------------------------------------------------------------
  152. Subject: Should software professionals be licenced/certified?
  153. Date: 27 Oct 1994
  154.  
  155. This is a very controversial and political question.  Generally, certification
  156. is something voluntary, while licencing is regulated by governments.
  157. Certification generally means some agency warrants you meet its standards;
  158. licencing generally means that to claim to practice a certain profession
  159. requires a government licence, often administered through a professional
  160. organization.  In theory both are supposed to help judge if someone is capable
  161. of doing certain jobs.
  162.  
  163. Licencing isn't currently required for computing professionals;  some people
  164. would like to see some jobs require it, as with established branches of
  165. engineering.  Others don't like government intervention, and/or believe many
  166. people who wouldn't get licenced are perfectly competent.
  167.  
  168. Computing professionals in the USA have had a certification program for years,
  169. administered by the Institute for Certification of Computer Professionals
  170. (708-299-4227), a meta-organization with representatives from ACM, IEEE-CS,
  171. ADAPSO, ICCA, IACE, AIM, DPMA, AISP, COMMON, ASM, CIPS, and AWC.  There are
  172. three certificates aimed at different broad types of practitioner, and many
  173. areas of specialization.  To keep a certificate requires at least 40 hours of
  174. continuing education each year; credit can also be obtained for self-study,
  175. teaching, publication, etc.
  176.  
  177.  
  178. ------------------------------------------------------------------------
  179. Subject: How do I get in touch with the SEI?
  180. Date: 27 Oct 1994
  181.  
  182. Try using the World-Wide Web via URL http://www.sei.cmu.edu/.  For general
  183. information about the SEI, contact the customer relations department of the
  184. Software Engineering Institute at:
  185.     internet:  customer-relations@sei.cmu.edu
  186.     Phone:  (412) 268-5800
  187. A subscriber service is available to U.S. mailing addresses. Subscribers
  188. receive the SEI quarterly newsletter, Bridge; invitations to SEI public
  189. events; and first notification of course offerings and new publications.  To
  190. become a subscriber, contact Customer Relations.
  191.  
  192. To order an SEI publication, contact NTIS, DTIC, or RAI directly:
  193.     National Technical Information Service (NTIS)
  194.     U.S. Department of Commerce
  195.     Springfield, VA 22161-2103
  196.     Telephone: (703) 487-4600
  197.  
  198.     Defense Technical Information Center (DTIC)
  199.     ATTN: FDRA Cameron Station
  200.     Alexandria, VA 22304-6145
  201.     Telephone: (703) 274-7633
  202.  
  203.     Research Access Inc. (RAI)
  204.     3400 Forbes Avenue
  205.     Suite 302
  206.     Pittsburgh, PA 15213
  207.     Telephone: (412) 682-6530
  208.     FAX: (412) 682-6530
  209.  
  210.  
  211. ------------------------------------------------------------------------
  212. Subject: What is the SEI maturity model?
  213. Date: 31 Jan 1992
  214. Originally-From: mcp@sei.cmu.edu (Mark Paulk)
  215. Archive file: maturity
  216.  
  217. Maturity is not an easy concept to get down to a single paragraph, but
  218. consider this.
  219.  
  220. Premise:  The quality of a software system is largely governed by the quality
  221. of the process used to develop and maintain the software.  Basics:  The first
  222. step in improving the existing situation is to get management buy-in and
  223. management action to clean up the software management processes (walk the
  224. talk, as TQMers frequently say).  Integration:  The second step is to get
  225. everyone working together as a team.  Measurement:  The third step is to
  226. establish objective ways of understanding status and predict where things are
  227. going in your process.  Continuous improvement:  Understand that this is
  228. building a foundation for continually getting better.
  229.  
  230.  
  231. ------------------------------------------------------------------------
  232. Subject: Where can I get information on API?
  233. Date: 31 Oct 1994
  234.  
  235. API stands for Application Programming Interface.  For a useful subset of
  236. standard APIs that NIST considers relevant to US Federal government needs, you
  237. can look at NIST SP 500-187 "Application Portability Profile," using the
  238. World-Wide Web via URL http://nemo.ncsl.nist.gov/app-ose/, or send mail to
  239. mail-server@nemo.ncsl.nist.gov with
  240.     send app-ose/app2.txt
  241. in the body, or contact Barbara Blickenstaff, 301-975-2816.  Many of the open
  242. systems APIs are being developed in the IEEE POSIX groups.  An article in the
  243. Dec. 1991 IEEE Spectrum describes these and related API standards.  IEEE
  244. standards aren't distributed electronically, but both of the documents above
  245. tell how to obtain copies.
  246.  
  247.  
  248. ------------------------------------------------------------------------
  249. Subject: What's a 'bug'?
  250. Date: 12 May 1992
  251.  
  252. You can take your pick:
  253.  (1)   Don't use "bug", use "fault" (an incorrect instruction or definition),
  254.        "failure" (an incorrect result), or "mistake" (a human action leading
  255.        to a failure).  Paraphrased from
  256.            IEEE Standard Computer Dictionary
  257.            Standard 610, ISBN 1-55937-079-3
  258.            Institute of Electrical and Electronic Engineers, Inc.
  259.            345 East 47th Street
  260.            New York, NY 10017-2394  USA
  261.            $49.50 (US$) for IEEE members
  262.  (2)   Beizer, in a footnote on page 33 of the second edition of _S_o_f_t_w_a_r_e
  263.        _T_e_s_t_i_n_g _T_e_c_h_n_i_q_u_e_s says (paraphrased):
  264.            I'm  sticking  with "bug" because everyone knows what it means,
  265.            there are several "standards" for other terms that  are  incon-
  266.            sistent  with  each  other,  the OED says that the conventional
  267.            computer meaning of "bug" is  ancient,  and  short  Anglo-Saxon
  268.            words are preferable to long Norman ones.
  269.  
  270.  
  271. ------------------------------------------------------------------------
  272. Subject: Where can I get copies of standards??
  273. Date: 28 Oct 1994
  274.  
  275. ISO, ANSI, and IEEE standards are usually sold to raise some of the funds
  276. that the various national and international standards bodies (who usually
  277. own the copyright) need to keep afloat; thus they are not normally avail-
  278. able electronically.  Also, the organizations are concerned that electron-
  279. ic copies would make it too easy for people to disseminate doctored ver-
  280. sions of the standards.
  281.  
  282. ISO standards may be purchased from:
  283. In Canada:
  284.     Standards Council of Canada / Conseil canadien des normes
  285.     1200-45 O'Connor,
  286.     Ottawa K1P 6N7
  287.     Phone: (613) 238-3222
  288.     Fax:   (613) 995-4564
  289. On CD-ROM:
  290.     Omnicom, Inc.
  291.     115 Park St. SE
  292.     Vienna, VA 22180-4607
  293.     1-800-OMNICOM
  294.     Also available through the National Technical Information Service
  295.     (NTIS), 5284 Port Royal Rd., Springfield, VA 22161, (703)
  296.     487-4650.
  297. ANSI and ANSI equivalent ISO standards are available from
  298.     ASQC Quality Press
  299.     Customer Service Department
  300.     P.O. Box 3066
  301.     Milwaukee, WI 53201-3066
  302.     Voice: (800) 248-1946
  303.     FAX:   (414) 272-1734
  304.  
  305. For ITU (formerly CCITT) standards, see the ITU using the World-Wide Web via
  306. URL gopher://info.itu.chor use their mail server: mail to itudoc@itu.ch with
  307. no subject and the following body:
  308.     START
  309.     HELP
  310.     END
  311. There were once some CCITT standards on-line at the University of Colorado,
  312. but the arrangement to make them available via the Internet was terminated at
  313. the end of 1991.
  314. -- 
  315. Software Technology Laboratory      dalamb@qucis.queensu.ca (David Alex Lamb)
  316. Computing and Information Science   phone: (613) 545-6067
  317. Queen's University, Kingston, Ontario, Canada K7L 3N6    
  318.  
  319.